home *** CD-ROM | disk | FTP | other *** search
/ Aminet 8 / Aminet 8 (1995)(GTI - Schatztruhe)[!][Oct 1995].iso / Aminet / dev / amos / AMOS_0695.lzh / AMOSLIST / 000090_amos-request@svcs1.digex.net_Thu Jun 15 18:23:49 1995.msg < prev    next >
Internet Message Format  |  1995-07-01  |  3KB
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id SAA27733;  for  ; Thu, 15 Jun 1995 18:23:47 -0400
  2. Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id RAA14017 for amos-out; Thu, 15 Jun 1995 17:01:17 -0400
  3. Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id RAA14014 for <amos-list@svcs1.digex.net>; Thu, 15 Jun 1995 17:01:13 -0400
  4. Received: from vortex.netbistro.com (root@vortex.netbistro.com [204.244.105.1]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id RAA18249;  for <amos-list@access.digex.net> ; Thu, 15 Jun 1995 17:01:11 -0400
  5. Received: by vortex.netbistro.com (Smail3.1.29.1 #9)
  6.     id m0sMM1k-000LVwC; Thu, 15 Jun 95 14:00 PDT
  7. Date: Thu, 15 Jun 1995 14:00:18 -0700 (PDT)
  8. From: Gau <gau@vortex.netbistro.com>
  9. To: Andy Church <achurch@dragon.mbhs.edu>
  10. cc: amos-list@access.digex.net
  11. Subject: Re: Music help
  12. In-Reply-To: <199506141641.AA03142@dragon.mbhs.edu>
  13. Message-ID: <Pine.BSD.3.91.950615134800.24374A-100000@vortex.netbistro.com>
  14. MIME-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Status: RO
  17. X-Status: 
  18.  
  19. On Wed, 14 Jun 1995, Andy Church wrote:
  20.  
  21. > [ memory fragmentation after loading and freeing multiple music files ]
  22.  
  23. To avoid fragmentation, load small stuff before the big stuff, and, if 
  24. you can, keep the small stuff in memory or reuse it (withOUT 
  25. deallocating).  This keeps the rest of memory free for your music to load 
  26. in and out.
  27.  
  28. Memory fragmentation happens when some small allocated area sits between 
  29. two blocks of memory, splitting the maximum available size in half.
  30.  
  31. Like:
  32.             200K - free
  33.         56K  - alloc
  34.         256K - free
  35.  
  36. If this is your chip memory, you just lost the ability to load anything 
  37. >256K into chip until the 56K allocation goes away.  This would be easy 
  38. to do.  The following code would cause the above fragment to occur:
  39.  
  40.     reserve as chip data 1,200*1024
  41.     reserve as chip data 2,56*1024
  42.     ...some code...
  43.     erase 1
  44.  
  45. Hopefully, if you know what causes fragmentation, you can write your code 
  46. to avoid it:
  47.  
  48.     reserve as chip data 2,56*1024
  49.     reserve as chip data 1,200*1024
  50.     ...some code...
  51.     erase 1
  52.  
  53. The second example will not fragment memory.  Another way to avoid 
  54. fragmentation is to approach your memory allocation like you would a 
  55. stack (the first thing allocated is the last thing deallocated).  The 
  56. closer you get to this kind of setup, the less fragmentation you'll get.
  57.  
  58. In short: Allocate first the memory areas that change the least (by change
  59. I mean change of allocation, by deallocating and reallocating.) ie: fonts,
  60. player sprites, etc.  Allocate transient memory areas (constant
  61. allocation/deallocation as in the case of music tracks) last.  This 
  62. avoids fragmentation. 
  63.  
  64. ==============================================================================
  65. Gau of the Veldt
  66.  
  67.   "Draped in monster hides, eyes shining with intelligence.
  68.    A youth surviving against all odds..."
  69.  
  70. == Email: gau@vortex.netbistro.com == WWW: http://vortex.netbistro.com/comp ==
  71.